It is known to generate an animation for one or more virtual objects (also termed “characters”) that are located in a virtual environment, such as a three dimensional virtual environment of a video game or visual effects tool.
For a virtual object, there may be a large number of actions or motions that may need to be represented as an animation of that virtual object. For example, a virtual object representing a human character may be animated so that the character walks, runs, hops, jumps, limps, skips, kneels down, falls down, crawls, looks or points in a particular direction, etc. An animation may be authored or created and data representing or defining the animation may then be stored so that the virtual object can be made to perform that action by animating the virtual object using the animation data when desired. Animation data may created, for example, by “key framing” or “motion capture”: in “key framing”, the animation is defined by collecting data representing the configuration of the virtual object at different points in time (key frames) and then interpolating between positions of the virtual object in successive key frames; in “motion capture”, animation data is obtained from sensors attached to a human actor. However, if these approaches were taken for every conceivable action that the virtual object may perform (or for those actions that one may wish the virtual object to be able to perform at some stage), then this would lead to an unfeasibly large number of animations being created and an immense amount of data being stored. For example, for the human character to be able to run at different speeds, the above approach would require an animation to be created and animation data stored for each desired speed.
Moreover, using such “canned” animation data is often unsatisfactory (e.g. they do not provide for sufficiently realistic, responsive or precise animations) for interactive applications such as video games and virtual reality simulations, i.e. applications in which a user has the choice to change the how the virtual object is being animated to perform character actions or goal-based commands, such as running at different speeds or in different directions.
Consequently, the approach normally taken is to have a smaller number of predetermined animations for a virtual object, and to store corresponding animation data for those predetermined animations. Two or more of these predetermined animations may then be blended (or mixed or combined) to form other animations for the virtual object. In particular, blend weights, or blending parameters, may be associated with the predetermined animations to represent how much those predetermined animations contribute to the final animation the final animation may then be created using the predetermined animations blended according to the blend weights. For example, the human character may have an associated predetermined “walk” animation and an associated predetermined “run” animation, in which case the human character may be made to jog by blending the walk animation and the run animation with blend weights of (1−α) and a respectively for some value 0<α<1, where larger values of a correspond to faster jogs.
An animation engine is the component or system or module that performs the animation of the virtual object. An animation engines may provide direct control of the blend weights (i.e. it may provide or expose an interface via which the animation engine may receive desired blend weights from another component or module). However, the use of animation blending, especially in interactive applications, normally involves the use of alternative values with a more intuitive meaning (control parameters) than blend weights. For example, in an interactive application the user may control the virtual object by using control parameters that are then transformed into blend weights by the animation engine. For example, when animating a human character, the animation engine may have an interface for controlling the speed of the virtual object, for example by receiving an input the specifies a desired speed in a particular unit, such as meters per second. Thus, for example, instead of providing the animation engine with the blend weights (1−α) and α for blending a “walk” animation and a “run” animation to generate a “jog” animation, the animation engine may be arranged to receive an input that specifies the actual speed for the jog. Such parameters or attributes of the animation that the animation engine is arranged to receive as its inputs are called control parameters. The animation engine may then convert one or more control parameters that it receives into blend weights for use in blending predetermined animations to generate an output animation.
In view of the foregoing, there is a need for an efficient system that computes, from respective values for a set of control parameters, corresponding values for the set of blend weights. In general, it is not possible to store, for all possible combinations of values for the set of control parameters, the corresponding values for the set of blend weights, since that would require an impractical amount of memory for most applications. To be practical, it is necessary to use only a small number of samples (or examples), where each sample indicates of how to map a particular group of values for the set of control parameters to corresponding values for the set of blend weights. However, this inherently produces lack of accuracy in the blending process that results when performing blending based on values for the set control parameters that are not represented exactly by one of the samples. Whilst accuracy can be increased by adding more samples, this makes the system less efficient since more memory is used and there is an increase in the number of computations required to process the larger number of samples.
Moreover, the conversion of control parameters to blend weights does not always result in an output animation of the virtual object that achieves the desired effect. For example, if a control parameter specifies that the human character should jog at 5 m/s, this may be converted into one or more blend weights which, when used in the actual blending of the predetermined “walk” and “run” animations, results in an output animation that actually achieves a jog speed other than 5 m/s, say 5.3 m/s. This may be due to how the blend weights are computed from the control parameters and/or how the blending is performed once the blend weights have been calculated, or due to other factors.
Consequently, there is a need for a more efficient technique that overcomes the drawbacks of using limited samples to compute blend weights from control parameters. It would also be desirable to have better control over the animations that the animation engine produces.